Internet of things security with multi-party computation (mpc)

ABSTRACT

A method and device for establishing a communication along a communications channel between a first device (200A) and a second device (200B) is disclosed. The method comprises mutually discovering the first device (200A) and the second device (200B), validating (F5, F6, F7) the communications channel between the first device (200A) and the second device (200B) by exchange of data messages, exchanging a secret between the first device (200A) and the second device (200B) and then exchanging encrypted messages along the communications channel.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to and benefit of Portuguese PatentApplication No 20181000034529 filed on 16 May 2018 and European PatentApplication No. 18 174 412.9 filed on 25 May 2018.

BACKGROUND TO THE INVENTION

Internet of Things (IoT) is a concept of how technology will interactwith people in the coming years. It is a collection of “things” ordevices connected to a network, such as a private Internet and/or thepublic Internet in which “smart” devices not only interact with people,but also interact with each other. Data released by Gartner's researchorganisation predict that there will be 25 (US) billions of such smartdevices connected to the Internet by 2020. These physical and virtual“things” have identities, physical attributes, virtual personalities,and react substantially autonomously to events in the real/physicalworld influencing these events with processes without direct humanintervention.

Due of the exponential growth in this area, there are several privacyand security challenges. In particular, there is a need to adaptsecurity solutions to the particular characteristic of IoT devices.There are resource limitations in the IoT devices which are not found inconventional devices [Ref 1]. These include limited battery life andmemory space in the IoT device. The set of security and privacyrequirements necessary for the IoT device include, but are not limitedto, user and device identity management, authentication, theconfidentiality of data exchanged in communications between differentones of the IoT devices, network access control to allow only authorizedones of the IoT devices access to the IoT network, and the availabilityof resources and systems [ref 2].

To date, most research and existing IoT platforms are focused on devicemanagement and employ trusted, centralized solutions for authenticationand security. These centralised solutions are based on a Public KeyInfrastructure (PKI). Despite the obvious advantages of using the PKI,solutions based on the PKI tend to be complex, expensive, and not easyto administer [ref 4]. In addition, there are the afore-mentionedresource limitations with a device that is connected to a PKI-basednetwork.

The physical security of the IoT devices is also known to be a problem,as any keys stored in a memory on the IoT device may be read off aphysically captured IoT device and used by an adversary to launch anattack against the IoT network in which the IoT device was incorporated[Ref 3].

The PKI relies exclusively on a Certificate Authority (CA) forvalidation of security certificates within the network (such as the IoTnetwork discussed above). The CA represents a single point-of-failurewithin the infrastructure of the network. While failure points are knownto exist in various protocols, it is highly desirable that these failurepoints should not be unique or centralized (such as in the CA) in orderto enable the networks to become more resilient to any attacks on thenetwork. The PKI is totally and irreversible compromised if the privatekey of the CA is disclosed. Any attacker obtaining the private key caneasily issue a new certificate and, therefore, impersonate and performso-called Man-in-the-Middle (MitM) attacks in the compromised network.The MitM attack is when the attacker secretly relays and possibly alterscommunication between two parties in the network who would otherwisebelieve that the two parties are actually directly communicating witheach other. For example, in the case of a simple disclosure of theserver certificate, a so-called “attack window” is opened during whichthe attackers can compromise the network. This attack window remainsopen that disclosed server certificate is revoked, which may not beimmediately done, for example if the attack is not noticed for sometime.

Another problem that is known to occur in the PKI is when poorly managedCAs sign certificates for a particular domain without correctlyverifying ownership over the domain.

Given the aforementioned limitations, the underlying assumptions in thePKI are not necessarily the best fit for the IoT network and the IoTdevices.

Diffie-Hellman (DH) key exchange is a method of securely exchangingcryptographic keys over a public channel in the network and is based onthe establishment of a shared secret between the two parties wishing tocommunicate over the network. DH key exchange is based on the conceptthat two parties (typically known as Alice and Bob) each establishsecret parameters, which are kept secret to themselves, and a startingparameter which is kept non-secret and agreed between the two parties.The starting parameter is mixed on both sides with the secret parametersand then exchanged as a public key. After exchange of the public key,the public key is mixed with the own secret parameters and both partiesthen have an identical value that can be used for encryption of thecommunication. Unfortunately, the DH key exchange is also vulnerable toMitM attacks since the DH key exchange does not provide authenticationof the communicating parties. The attacker can therefore impersonateboth Bob and Alice, i.e. the communicating parties.

Several protocols are known in which the two parties can communicatedirectly with each other to confirm their identity by passing andconfirming a Short Authentication String (SAS). These protocols includeZ Real-time Transport Protocol (ZRTP) [ref 9] and Password AuthenticatedKey Exchange by Juggling (J-PAKE) [refs. 5 and 7] and are based on thepremise of human interaction and manual provisioning. Such knownprotocols are not, however, suitable for communication with the IoTdevices as the protocols are based on human interaction, which is notpractical between pairs of the IoT devices.

Other solutions on offer include the PAKE (Password-Authenticated KeyAgreement) protocols. Currently, the most sophisticated algorithms donot perform key exchanges based on public key cryptography and allowlow-entropy passwords to be used. In Ref 6, the three state-of-the-artPAKE protocols are discussed. In the same paper, there are alsodisclosed two protocols that are more efficient than the J-PAKEprotocol, which were adopted as the defaults in the OpenSSL environment.

The J-PAKE protocol [Refs. 5 and 7] is based on a concept of a sharedpassword, which does not require a PKI or a third party in order toestablish a secure communication between two parties. J-PAKE uses anelliptic curve DH for the key agreement and Schnorr Non-InteractiveZero-Knowledge (NIZK) signatures [Ref 8] proof mechanism to authenticatethe two parties and establish a shared secret between the two partiesbased on a passphrase. There are some services that still use the J-PAKEprotocol, such as the Pale Moon Web-Browser, the lightweight API inBouncycastle (version 1.48 and onwards), and the Thread (IoT wirelessnetwork protocol). This protocol was also previously supported byFireFox Sync, OpenSSH, and OpenSSL, but was removed after 2014.

There are several known J-PAKE issues, already published by MohsenToorani [Ref 12]. Ref. 12 presents an analysis of J-PAKE, as used byFirefox Sync, and has identified vulnerabilities in J-PAKE. For example,J-PAKE is vulnerable to a password compromise impersonation attack andhas other shortcomings with respect to replay and Unknown Key-Share(UKS) attacks. J-PAKE has also been included in OpenSSL and OpenSSH, butproblems were reported during implementation [Ref. 25].

Device Pairing Using Short Authentication Strings [Ref. 22] is atwo-device pairing mechanism based on the agreement and checking of asecret's authenticity using the SAS. This protocol comprises threephases: discovery, agreement, and authentication. When the pairingservice starts, the server starts publishing a chosen instance name. Theclient will discover that name and the corresponding connectionparameters [Ref 22]. After the server is discovered, the client andserver use a transport layer security (TLS) session which allows theclient and server to agree on a shared secret using a cryptographicprotocol that produces the SAS. After the completion of this phase,there is an authentication phase, used to validate the pairing throughthe SAS. In this authentication phase, the comparison of the SAS is madethrough a manual verification, i.e., the user has to verify that both ofthe devices (server and client) wishing to communicate display the samestring. If, instead, the server and client support Quick Response (QR)codes, then the server displays a QR code with the encoding of the SAS,and the client is capable of scanning the value of the SAS and comparingthe scanned value to a locally computed value.

ZRTP [ref 9] is a two-point multimedia communication protocol thatcontains a session set-up phase used to agree on key exchange andparameters for establishing Secure Real-Time Transport Protocol (SRTP)sessions. This ZRTP protocol is not based on digital certificates, buton DH keys generated in each session (and discussed earlier). These DHkeys contribute to the generation of the session key and parameters forthe SRTP sessions. Although the ZRTP protocol initially needs to use asignalling protocol, such as a Session Initiation Protocol (SIP), thekey negotiation is performed only by the ZRTP implementation. The DHalgorithm, alone, does not provide sufficient protection, however,against MitM attacks. To authenticate both peers in the key exchange inthe ZRTP protocol, a SAS is used that is distributed to both phones andcompared verbally by both ends. If the SAS is the same, then both of theusers must press a button in order to accept the key.

U.S. Pat. No. 7,730,309 teaches a method and system for a securetelephone protocol. The secure telephone protocol can include a sharedsecret value that is cached and is then later re-used to authenticate along series of session key which are used for separate secure phonecalls. This enable cryptographic key continuity without the need forvoice authentication by a user. The system of the patent utilizes the DHkey exchange during call setup and thus suffers the limitations set outabove.

As noted above, the existing solutions do not provide a satisfactoryauthorisation and encryption method for exchanging messages, includingdata, between IoT devices in the IoT network.

SUMMARY OF THE INVENTION

There is need of a new approach for autonomous mutual pairing throughthe exchange of a short authentication string (SAS) that does notinvolve human interaction by a user for the validation of the SAS andthe security of a communications channel.

This disclosure teaches system and method a so-called key exchange withautonomous verification using multi-party computation between twodevices. The key exchange is used for establishing secure communicationsbetween any two parties, such as the IoT devices, devices implementing aVoice over IP (VoIP) protocol, or other units in the network. The systemand method are based, for example, on a Diffie-Hellman (DH) keyexchange. The method and system described in this document does not,however, require the presence of a PKI or any trusted third party, suchas a Certificate Authority.

Multi-party computation (MPC) poses itself as a suitable option foroffering the basic building block for building decentralised privacypreserving computational frameworks. The goal of MPC is to enableparties to compute some joint function of their own private inputs [ref13]. This protocol must preserve some security properties: thecorrectness of the outputs and privacy of inputs, even if some of theplayers are corrupted by an active or passive maliciously adversary[ref. 14], i.e., without revealing more information than the output ofthe function itself.

The method of this disclosure is implemented as follows for establishinga communication along a communications channel between a first deviceand a second device. The first device and the second device are localdevices and could, for example, be members of an IoT network comprisinga plurality of such devices, or a VoIP network. The devices in the VoIPnetwork are devices for transmission of voice-based messages.

The method comprises mutual discovery of the first device and the seconddevice by, for example, exchanging initiation and acknowledgementmessages between the first device and the second device. This mutualdiscovery can be carried out by an automatic exchange of messagesbetween the first device and the second device as a directcommunication. One alternative, used for example in the afore-mentionedVoIP network, is the use of a centralised server, called a SIP server,which is able to authenticate the communications channel between thefirst device and the second device. Secret session keys are thenestablished between the first device and the second device.

The communications channel between the first device and the seconddevice is subsequently validated by calculating a first SAS in the firstdevice and a second SAS in the second device and then inserting thefirst SAS in a first MPC module in the first device and the second DASin a second MPC module in the second device. The multi-partycommunications (MPC) modules confirm the security of the communicationschannel by evaluating the first SAS in the second MPC module and thesecond MAS in the first MPC module. Subsequently, a shared secret isestablished between the first device and the second device usingmulti-party computation and encrypted messages can be exchanged alongthe communications channel.

In one aspect of the disclosure, the authentication by exchanging ofinitiation and acknowledgement messages comprises generating a randomnumber identifier of at least one of the first device and the seconddevice. Thus, the devices receive different identifiers for eachcommunication session for the exchange of communications. As notedabove, in a VoIP network, the mutual discovery will be carried out byusing a so-called SIP server (SIP=session initial protocol) which knowsthe identities of the devices which can use the VoIP protocol.Subsequent data transfer in the VoIP network is made in a peer-to-peermanner.

The method further comprising sending a confirm message from the firstdevice to the second device and a confirm message from this seconddevice to the first device after successful comparison by multi-partycomparison.

It will be noted that the SAS is, in one implementation of the method,identical in both the first device and the second device and themulti-party communication module implementing the validation of thecommunication channel is adapted to check that the SAS received from thefirst device is equal to that generated in the second device.

In one aspect of the disclosure, the first secret key is generated froma previous first secret key and the second secret key is generated froma previous second secret key and in other aspect of the invention andthe validating of the communications channel is carried out beforeexchanging every message along the communications channel. In a furtheraspect, the validating of the communications channel is carried out onlyafter exchanging a number of messages along the communications channel.

This disclosure also teaches a network employing this method to enablesecure communication between the local devices in the network. Thedevices comprise a transmitter for transmitting messages along acommunications channel to one or more of the other ones of the pluralityof devices, a receiver for receiving messages from the communicationschannel from one or more of the other ones of the plurality of devices,a multi-party computation module for authenticating the communicationschannel by comparing a generated SAS with a received SAS, and anotherone of the plurality of device and generating a session key, acommunications module for encrypting messages using the generatedsession key.

The devices may also further comprise a storage for storing a pluralityof session keys and may also further comprises a pseudo random numbergenerator for generating a pseudo-random number identifying the devices.

DESCRIPTION OF THE FIGURES

FIG. 1A shows a first communications scheme between two parties.

FIG. 1B shows a second communications scheme between two parties.

FIG. 2 shows an overview of the network with two devices.

FIG. 3 shows a connection of two devices being Raspberry Pi processors.

DETAILED DESCRIPTION OF THE INVENTION

The invention will now be described on the basis of the drawings. Itwill be understood that the embodiments and aspects of the inventiondescribed herein are only examples and do not limit the protective scopeof the claims in any way. The invention is defined by the claims andtheir equivalents. It will be understood that features of one aspect orembodiment of the invention can be combined with a feature of adifferent aspect or aspects and/or embodiments of the invention.

The work described in this document involves a design and implementationof a system and method for secure peer-to-peer data exchange between two(local) devices in a network, and more particularly in an IoT networkand a VoIP network. The system and method are a decentralised solutionfor the authentication of the communication between the two device and,unlike the prior art PKI, are not a centralized solution and the systemand method of this document has no single point-of-failure. The use inpeer-to-peer data exchange does not preclude the use of the system andmethod in a network in which one or more central servers are present andcan also communicate with the local devices.

The system and method have a lightweight architecture and thereforeprovide a solution for an IoT environment with a plurality of individualIoT devices and other units in an IoT network without additionaloverheads. The system and method are adaptable for differentrequirements. As explained below, users of the IoT network canprioritise speed or introduce additional security checks, which willincrease the runtime overhead.

The system and method do not rely on human intervention and cantherefore be used for secure Voice over IP (VoIP) communications. Themethod can be adapted to ZRTP VoIP application and thus eliminate theneed for human intervention, or to validate a communications channel, aswill be explained later.

The system and method make use of the concept of multi-party computation(MPC). This is a sub-field of cryptography which was formally introducedas a form of secure two-party computing in 1982 and generalised in 1986by Andrew Yao's [see Refs. 13, 30 and 31]. The idea behind MPC is toperform computations privately. In this case, suppose that N partieswant to compute a function

EQf(t\s\do5(1)\, . . . \,t\s\do5(N))=S  (Eqn. 1)

where the party i is responsible for input t_(i).

The goal is that neither of the parties can obtain more informationbeyond the pair (t_(i); S), i.e. the input t_(i and) S, the result ofthe function f. No input t_(i) from the party i can be revealed to anyof the other parties, and each party receives only its output. Onenon-limiting example of the function is the equality function, which isimplemented in an MPC module. Suppose two parties, i.e. two IoT deviceseach have an input t₁ and t₂. The MPC module receives individually fromeach of the two IoT devices the corresponding values t₁ and t₂. The MPCmodule returns the value S=1 if the values of t₁ and t₂ are equal andthe value S=0 if the values t₁ and t₂ are not equal. In the latter case(i.e. S=0) this could mean that there is a man in the middle attachpresent and the communication between the two IoT devices cannot betrusted to be secure. This concept can be adapted to other parties, suchas devices implementing a VoIP protocol.

There are some properties that must be present in the MPC protocol inorder for the MPC protocol to be secure. The MPC protocol has toguarantee privacy, which means ensuring that no one (apart from theparties themselves) will know the inputs t_(i) of the parties i, i.e.,each party i only knows the output S of the function shown in Eqn. 1,which is the answer to the requested problem. Take as an example, anauction, where the only bid revealed is that bid of the highest bidder.It is clearly possible to derive that all the other bids were lower thanthe winning bid. However, this should be the only information revealedabout the losing bids. Another property that the MPC protocol must haveis correctness, whereby it must be guaranteed that each one of theparties i receives the correct output S. In the example of an auction,this implies that the party i with the highest bid is guaranteed to win,and no party, including the auctioneer, can alter this result [seediscussion in Ref 32].

The system and method of this document are based on an DH key exchangeto overcomes the complexity of PKI systems or the use of a trusted thirdparty. As discussed in the introduction, DH alone cannot ensureauthentication, and DH has an MitM problem [see Ref. 10 for moredetails].

Zimmermann P. et al. [Ref 34] proposed a solution to this MitM problemby using a “double check”. This double check allows the detection of anyof the MitM attacks through displaying the SAS for each of the users inthe PKI system to read aloud the SAS and enable the parties to verballycompare the SAS over the phone in a Voice Over Internet Protocol (VoIP)communication (or indeed communication over any other protocol allowingvoice communication over an audio channel). The users must activelypress an “ok” button on, for example, a touchscreen or a return key on akeyboard to confirm that the SAS is equal. This solution (termed theZRTP protocol) lacks, however, the possibility of adapting this protocolfor pure data exchange without the audio channel and thus no aural ororal communication is possible. In other words, a protocol for theexchange of data using the idea of Zimmermann of comparison throughvoice cannot be used because there is no audio or secure channelestablished through which it is possible exchange automatically the SASsecurely without intervention from the user. One further issue with theZRTP protocol is that “lazy” or “irresponsible” users may simply confirmthe SAS without really verifying that the SAS is equal.

The system and method of the current document solves this authenticationproblem by adding an extra security layer based on the MPC sub-field ofcryptography. This extra security layer comprises two (or more) parties,wherein each one of the parties has their own input. Suppose now thatboth of the parties wish to perform some computation on an item of data,without revealing their own input to the data to other ones of theparties or to the network as a whole. It is necessary to compareautomatically the SAS privately and without human intervention. Inaddition, the validity of the SAS is assured at any moment in timebecause, for extremely sensitive communications, this double-check iscritical. The automatic comparison of the SAS also eliminates the riskof the lazy or irresponsible user confirming the SAS without reallychecking its validity.

FIG. 1A illustrates the communication scheme between two devices (200Aand 200B) in an IoT network shown in FIG. 2 using the system and methodof the current document. FIG. 1B shows an adaptation of thecommunications scheme when the two devices 200A and 200B are devices forcommunicating using a Voice over IP protocol. It will be appreciatedthat in such a case the two devices 200A and 200B could be smartphones,tablets or computers, but this is not limiting of the invention.

FIG. 2 shows two devices 200A and 200B that can communicate with eachother and exchange data in the form of messages with each other. Themessages can be purely data messages or could be packets with voice datausing the VoIP protocol. The two devices 200A and 200B include amultiparty computation module 210, whose function will be explainedlater, and identifier file 220 for storing and caching a session key.The two devices 200A and 200B also include a transmitter 240 and areceiver 250 as well as a power source 260. The two devices 200A and200B are, for example, sensors with a limited amount of storage andpower available.

The communications scheme in FIG. 1A between the two devices 200A and200B starts with both of the devices 200A and 200B automaticallyexchanging HELLO and HELLOack messages (acknowledgement of receipt ofthe HELLO message) in steps F1 to F4 using the transmitters 240 andreceivers 250. This exchange of messages occurs without interventionfrom a user and is shown as Phase 1 on the Figure. In these HELLO andHELLOack messages, the identification of both of the two devices 200Aand 200B are revealed to each other. The identification is generatedusing a Pseudo Random Number Generator (PRNG) and this identification isvalidated during the Phase 1. After this exchange of messages in Phase1, the key agreement exchange in Phase 2 can begin with a Commit messagein step F5 from the device 200B to the device 200A. The scheme shown inFIG. 1A assumes that the device 200B is the initiator. There are twoapproaches that can now be carried out in order to agree a key betweenthe device 200B and the device 200A.

In a first approach the devices 200A and 200B exchange a new sharedsecret through the DH exchange. This is shown in steps F6 and F7. In thesecond approach, the devices 200A and 200B do not need to exchange a newshared secret because there already exists a shared secret that has beenpreviously exchanged between the devices 200A and 200B. As a result, theDH calculation in this second approach is omitted by the devices 200Aand 200B. However, the so-called DHPart1 and DHPart2 messages in stepsF6 and F7 are still exchanged between the devices 200A and 200B todetermine which one of the several stored shared keys in the devices200A and 200B should be used. The DHPart1 and the DHPart2 messages aredefined in the ZRTP protocol and are the public DH values. Instead ofthe DH values (hvi and pvr), the devices 200A and 200B use nonces, alongwith the retained secret keys, to derive the key material [Ref 26]. Thisis described in detail in the RFC document 6189 ZRTP: Media Path KeyAgreement for Unicast Secure RTP from the Internet Engineering TaskForce (ISSN 2070-1721), see section 4.41.1 (downloadable athttps://tools.ietf.org/html/rfc6189#section-4.4.1.1).

The communications scheme in FIG. 1B is similar to that shown in FIG.1A, except that the discovery of the communications channel betweendevices 200A and 200B is not carried out by sending a Hello message andreceiving a HelloACK response in Phase 1. The two devices 200A and 200Bare both known to the SIP server (which is a central server) and thusPhase 1 involves the exchange of the identifications of the two devices200A and 200B (which are local devices) from the SIP server to the otherone of the two devices 200A and 200B. After the exchange of theidentifications of the two (local) devices 200A and 200B using thecentral SIP server, data can be exchanged directly between the two(local) devices 200A and 200B.

After completion of these steps F6, in Phase 3 the multipartycomputation (MPC) module 210 in each of the devices 200A and 200B isused to make an automatic validation of the SAS by comparison, asdescribed above. The SAS is a series of letters and numbers which isgenerated from the session key of the two devices 200A and 200B. Thegeneration of the SAS value is described in the ZRTP RFC(https://tools.ietf.org/html/rfc6189#section-4.5.2), KDF uses a HMAC(https://tools.ietf.org/html/rfc6189#section-4.5). Any differences inthe session key which has previously been negotiated between the devices200A and 200B will generate different values for the SAS at the twodevices 200A and 200B.

In the non-limiting case described above the MPC module 210 implementsthe equality function to test whether the generated SAS in the device isequal to a received SAS from another device, and the MPC module 210returns the value S=1 if this equality is verified, i.e. the SASgenerated in the two devices 200A and 200B is the same and thus thecommunication between the two devices 200A and 200B. It is then possiblefor the two devices 200A and 200B to send a Confirm message in steps F8to F10 to the other one of the two devices 200A and 200B indicating thatthe other device has accepted and verified the SAS. (Phase 4). Finally,the communications protocol is ready to start sending data in thissecure session. In the event that the value S=0, indicating that thevalidation has failed and there is a possible man-in-the-middle attack,then no communication will be established between the devices 200A and200B.

The method and system take advantage of some additional security andprivacy properties as forward secrecy in order to guarantee confidentialcommunication in the future. For example, when the two devices 200A and200B performs multiple connections at different times with each other,the method and system rotate the keys between each ones of the sessionsso that the same key is not used in a following session. This way, thekeys used for the different communications over the multiple connectionsare different.

The identifier file 220 in each of the devices 200A and 200B caches thesymmetric key used to compute the secret session keys, and these secretsession keys change with each session. Suppose an attacker gets accessto the local seed which was used and will be used to derive the futureand current session keys, which property is termed forward secrecy. Theattacker will not be capable of reproducing or replaying any of theprevious exchanges of data in the communications between the two devices200A and 200B because of the property of forward secrecy. The attackercannot recompute the secret session keys for previous sessions form theaccessed local seed. In other words, if a single communication iscompromised then only this single communication (exchange of messages)will be compromised, but not other exchanges of messages in differentcommunications or sessions. This could happen if the session key forthis single communication session being somehow “leaked”, then this leakof the session key does not compromise the confidentiality of all of theprevious communications prior to the current communication.

In this way, the system and method are able to provide additionalprotection in the communication because, even if the devices 200A and200B do not bother with exchange the SAS before the communication, thereis still fairly decent authentication against a MitM attack, based on aform of key continuity, as explained in the following paragraph.

The idea of key continuity is that the session key is used only once forthe exchange of communication during that session, but the session keyis itself used as a seed to generate the session key for the followingsession with exchange of communications. This session key for thefollowing session can be subsequently used as the seed for thegeneration of further (subsequent) session keys, and so on. In otherwords, the old session key is used to generate the new session key and,as a result, the complexity of the session keys becomes greater witheach use and the session keys become more secure.

The negotiation of the session keys between the devices 200A and 200B isdone by generating a sequence of letters and numbers as the SAS. Thesize of the SAS can be defined. As discussed above, the SAS must beequal at both devices 200A and 200B. In the case of ZRTP, any attempt tocapture and decrypt the voice used as the SAS will cause the sequencesof letters and numbers to be different. The sequence is a mathematicalfunction derived from the initial key of both devices 200A and 200B, sothat any differences in the session key apparently negotiated betweenthe devices 200A and 200B will generate different values for the SAS.

This key continuity solution is suitable in the context of the IoTnetwork, as the number of IoT devices in IoT networks are increasing andautomatic provisioning of the session keys is necessary, so there is noneed for provisioning individually the session key to each ones of thedevices 200A, 200B beforehand. Moreover, with this solution, end-to-endprivacy is obtained without the use of the PKI.

The system and method have three different possible modes for thissystem, as is shown in Table 1. Users can choose which one of the threemodes best suits the implementation in question.

This first mode of use is entitled the “Without Key Continuity Mode.”This first mode takes advantage of the existing mechanism of the ZRTP,presented in the section 4.9.1 of the ZRTP draft [Ref 9], in which animplementation without a cache in any device is suggested. This featurewill allow the system and method to always be executed in DH mode (basedalso on the ZRTP DH mode [Ref 9]. In this first mode, it is mandatory tocompare the SAS using the MPC between the devices to validate thesession.

This first mode is a safe state with some security issues solved. One ofthe security issues is the impossibility of an opponent being able toobtain the local shared secret. In this first mode, the connectionbetween the devices 200A and 200B is always considered to be a brand-newconnection, in which the devices 200A and 200B have never agreed on asession key for communication between the two devices 200A and 200Bbeforehand. Therefore, this new connection is not “derived” from theprevious connection and the Key Continuity Property cannot be used tocreate a new key. This first mode does not require any additionalstorage in memory on any of the devices 200A or 200B to store previouslyused keys from which the new key will be derived. However, this firstmode does add overhead to the network connecting the two devices 200Aand 200B due to the need to perform MPC for every new connection. Thisextra overhead needs to be taken into consideration and balanced withthe other requirement to have extra storage in the devices 200A and200B.

The second mode is a normal mode and is based on the existing mechanismof the ZRTP, presented in the section 4.4.2 of the ZRTP RFC [Ref. 9] andis denoted the pre-shared mode.

In this second, normal mode, the key continuity feature is used so thatit is not necessary to always compare the SAS in all iterations usingthe MPC. However, this comparison will happen after every N connectionsare made between the two devices 200A and 200B. The value of N can bedefined by the user. In one non-limiting aspect, the default value of Nis 10. In other words, after every 10 exchanges of communication, it isverified that the protocol is running as expected.

The forward secrecy and key continuity properties are preserved in thissecond mode.

The third mode is a “paranoid” mode for the case in which it isnecessary at each iteration, i.e. each separate establishment of thecommunication between the two devices 200A and 200B, to verify thesecurity of the communication between the two devices 200A and 200B.There will be no derivation of keys or storage of keys from which newkeys can be derived. This paranoid mode will be used, for example, inquestions of anonymous or sensitive data. These paranoid modes will havemore complexity in order to assure an extra safety check. There willalso be a modified, “safe” mode that does not have the extra securitychecks, but which will generate the SAS for few iterations and truststhe key continuity thereafter.

In this third “paranoid” mode, the key continuity is also used as in thesecond normal mode. However, this third mode is “paranoid” as the thirdmode requires extra verification by comparison of the SAS to ensure thatthe SAS at both of the devices 200A and 200B is equal and that there wasno error. In this third mode, the MPC is used on all connections atevery iteration to compare the SAS.

It will be appreciated that this third mode requires a greater overheadin the network and on the devices 200A and 200B order to assure theextra safety check. This third mode is desirable for more sensitive databecause this third mode guarantees in all connections that the protocolran normally, and that the SAS is equal in the two connected devices.

In this third mode, only the concept of the key continuity is used.

As noted above, the system and method of this document is used in IoTnetworks, such as shown in FIG. 2. It can be assumed that the devices200A and 200B in the IoT network have few resources, there are severaltypes of systems, there are various types of operating systems, and areable to adapt to various types of use. Based on these assumptions, thesystem and method offer the following characteristics.

Usability. As noted above, some secure proposals in the prior art doexist, but, in order to apply these prior art secure protocols, manyprocedures are necessary, and many of the prior art secure protocolsrequire previous key changes. It will be recalled that, the exchange ofthe session keys by unsecured means (unencrypted email for example overthe open Internet) can compromise all of the security of the process forthe exchange of communication between the devices.

The method and system of this documents is easy to use. This can becompared to the case of J-PAKE, for example as implemented in FirefoxSync. J-PAKE is less easy to use, since JPAKE requires that the SAS bewritten to provision the two devices. In the method and system of thisdocument, the provision of the SAS is an automatic and secure processand the process is transparent for the user (through the combinationwith MPC that compares the SAS). As noted above, the devices 200A and200B in the IoT shown in FIG. 2 often do not have a screen on which itis possible to display information about the SAS to enable a human tocarry out the pairing of the two devices 200A and 200B, or at leastusers cannot interact with this screen easily and thus it may benecessary to have a keyboard or another device.

Lightweight. The existing limitations of the devices 200A and 200B inthe IoT network, i.e. low power and processing, are well known. Thismakes the use of a PKI difficult to use in the IoT network. The methodand system of the current document address these issues, as the methodand system are more suitable for low-resource devices without any needfor the PKI, key certification, trust models, certification authorities,etc., which bring with them inherent complexity.

Decentralised. This method and system differ from the PKI because thesystem is decentralised and does not rely solely and exclusively on asingle a CA, but rather encompasses a number of reliable, independentelements.

The implementation of this method and system is based on two libraries:ZRTPCPP [Ref. 15], which is a C++ implementation of the ZRTPprotocol—GNU ZRTP C++ and ABY [Ref 17] framework which efficientlycombines secure computation schemes based on arithmetic sharing, Booleansharing, and Yao's garbled circuits, and makes available best-practicesolutions in secure, two-party computation [Ref 29].

ZRTPCPP. The library ZRTPCPP is used.

Some adaptations were made, and some features added to the ZRTPCPPlibrary. In order to prevent a collision of the SAS, which can originatethe MitM attack, the inventors increased the cipher key size (theAdvanced Encryption Standard (AES) key), producing a new version of theSAS with a greater size. The collision of the SAS could happen when theMitM attack happens by chance to generate the same SAS or is able to runthrough combinations of possible SAS before detection. The increase insize of the SAS adds an extra degree of security regarding thecommunication cipher and also makes the collision of the SAS harder foran attacker. It will be appreciated that the more difficult it is tocreate unintentional collisions, then the better the quality of thealgorithm.

In order to support the pre-shared mode, the ZRTPCPP library was alsoadapted to support an SAS-verified flag that indicates that the SAScomparison between any of the devices 200A, 200B was made successfullypreviously and that the communications channel was therefore validated.Normally, in the standard ZRTP, the concept of the verified SAS is neverdefined, because the verified SAS requires some complexity and extrastorage is required to add an extra interface to accept the verifiedSAS. The method and system of this document has the previouslyadditional layer of MPC that takes away the complexity of the userinterface. As noted above, the use of MPC to compare the SASautomatically without the need for manual intervention by the user [Ref.9].

In both applications of the method and system, i.e. VoIP or IoT, thesame changes are made at this level. However, in the IoT use case, it isnot necessary to keep the interface to accept the SAS, while in the VoIPuse case, the MPC is used as a first or second factor authentication (tobe sure that the SAS is equal, and that the call along thecommunications channel is secure) and so, the extra interface to acceptthe SAS is maintained.

ABY. The library ABY combines secure computation schemes providing threedifferent secret sharing schemes: Arithmetic sharing, Boolean sharing,and Yao's garbled circuits. These secret sharing schemes allowstwo-party computation, for example between the devices 200A and 200B, tobe secure. The ABY library also allows the pre-computation of almost allcryptographic operations and provides novel, highly efficientconversions between secure computation schemes based on pre-computedoblivious transfer extensions [Ref 17].

This ABY library only considers semi-honest (passive) adversaries. TheABY library assumes a computationally-bounded adversary who tries tolearn additional information from the messages exchanged during thecommunication between the two devices 200A and 200B during the protocolexecution. The adversary cannot deviate from the protocol, so the ABY isprotected against passive insider attacks by administrators orgovernment agencies, or when the parties can be trusted to not activelymisbehave.

This implementation in the ABY library includes some sampleapplications, such as the Millionaire's Problem, secure-computation AES,Euclidean Distance, and some others that can be found in the GitHubsource code [Ref. 17]. The Millionaire's Problem was used with anadaptation for the input obtained from a local file on the computer. TheMillionaire's Problem was adapted to an equality problem.

For this adaptation, the inventor built a so-called equality problemcircuit with the following function

-   -   $out=bc->PutEQGate(s_alice, s_bob);$        instead of the call of the greater than equal function in the        Boolean circuit class:    -   $out=bc->PutGTGate(s_alice, s_bob);$

A new parameter was added to the function $test_equality_prob_circuit$in order to pass the SAS to the function by parameter, within the$showSAS$ function of the ZRTP. In this system, the MPC has only thefunction of comparing the SAS and guaranteeing that the SAS exchanged bythe protocol is correct.

In terms of the implementation and setup for both of the ZRTPCPP and ABYlibraries, there are some necessary changes needed to the publishedprotocols. It is known that both the ZRTP and the MPC protocols usepeer-to-peer scenarios. It was therefore necessary to define which onesof the devices 200A or 200B initiates the process (i.e. the sender) andwhich one is the receiver. The combinations made between the librariesmeant therefore that the device 200A or 200B which is the receiver ofthe ZRTPCPP became party 0 of the MPC, and the other device 200A or200B, i.e. the sender, became party 1. This is merely a design issue andis not limiting of the invention.

The integration of the ZRTPCPP and ABY libraries was carried out usingthe cmake platform. In terms of execution, when the ZRTP protocol wouldhave made the SAS display on a screen (which is of course not possiblein the implementation described in this document), a new layer ofverification of this SAS was added. On the other hand, the ABY frameworkwas to make the verification of the equality of the SAS.

In this implementation, there are two schemes. The first scheme is whenthe exchanged SAS between the two devices 200A and 200B is equal. Inthis first case the data can be exchanged securely and privately betweenthe two devices 200A and 200B, as noted above. In the second case, thecomparison shows that the exchanged SAS is different. The method andsystem abort the attempted communication without any exchange of thedata or information between the two devices 200A and 200B. It will beassumed that, in this second case, when the SAS is different, there isprobably an MitM attack in the communication.

In the following paragraphs, the security of the system is analysed, andsome known attacks are described, as well as evaluating the success ofthe system against these attacks. This analysis is done with respect toa threat model that describes the necessary and sufficient scenarios—allfrom a hypothetical attacker's point of view.

Threat Model. The ZRTP caches the symmetric keys used to compute thevalues of the secret session keys, and these computed values change witheach session, as discussed above [Ref 9]. If someone steals the ZRTPshared secret cache from the memory of one of the devices 200A or 200B,the attacker gets one unique chance to mount an MitM attack in the verynext session as it can generate the session key for the next session.This is possible in the method and system. It will be noted that themode “Without Key Continuity” described above solves this problem, sincethe session key is generated anew. The ZRTP shared secret cache isalways deleted from the memory at the start of each new session andalways executes the system and method in DH mode (based on ZRTPDiffie-Hellman mode [Ref 9]), as described above. Nevertheless, there isalways the necessity of comparing the SAS with the MPC.

It is possible for a collision of the SAS to occur, as discussed above,enabling an MitM, i.e., an honest user can have one SAS key, and theattacker can get or identify the same key and thus intercept the callthrough an MitM [See Ref 35]. However, this attack can be prevented byincreasing the size of the SAS to reduce the chance that the attackergenerates the same SAS key, as is carried out in this method and wasdescribed above. This is performed, as shown in the RFC of ZRTP [Ref 9],by increasing the cipher key size (the AES key) and thus producing thenew SAS with a greater size. The increase in the size of the SAS addsgreater security regarding the communication cipher and also makes thecollision of the SAS harder for an attacker.

In the MPC library stored on the devices 200A and 200B, an adversary canlaunch an MitM attack, as there is no authentication at all. ABY usesthe semi-honest (passive) adversary model, assuming a computationallybounded adversary who tries to learn additional information from themessages seen exchanged during the execution of the method. In contrastto the stronger malicious (active) adversary, the semi-honest adversaryis not allowed to deviate from the protocol [Ref 29]. The adversariescan explore the malicious (active) adversary model. An active attackmeans that the attacker interferes with and modifies the normalexecution of the protocol. The attacker does not simply observe whathappens in the network in a “passive” way.

Attack Scenarios. In this subsection, the security of the proposedsolution was measured and the security of the method against differentscenarios of attack was determined. This way, the inventors were able toclassify the security of the method and system outlined in thisdocument. This security was based on a set of theorems, adapting thoseused by Afifi et al. [Ref 38] to demonstrate that the authenticationprotocol was secure. To complete the evaluation, the inventors also addtwo new theorems.

Supposition 1. The method is secure against de-synchronisation attacks.The proof is based on the following. The manner to avoidde-synchronisation attacks is shown in FIG. 1 in which a uniqueidentifier is used to store information in the identifier file 220related to this device 200A or 200B in a database. When one of thedevices 200A or 200B sends the message F7 there is an update to thelocal cache in the memory of the devices 200A or 200B and the secretkeys are then rotated in the memory. If, for example, the memorycorrupts the information, or another type of problem occurs, both of thedevices 200A and 200B will not be capable of negotiating the session keyin the pre-shared mode. Both of the devices 200A and 200B will drop tothe first stage and a new DH key change in steps F6 and F7 will beperformed.

Supposition 2. The method and system outlined in this document is secureagainst tag impersonation attacks, based on the security provided by thecombination of PRNG's and the locally stored secret keys.

Proof. Each of the devices 200A and 200 B have a unique identifier—asshown in the FIG. 1 in steps F1 and F3, and which is generated by thePRNG. The unique identifier is used for communication with any otherdevice. Suppose an attacker obtains the identifier for device 200A, thenthe attacker could attempt to impersonate device 200A and send thedevice 200A's identifier to the device 200B. The attacker will not beable to do this because, as explained previously, there is theidentifier file 220 in the local cache that caches symmetric keymaterial used to compute the session keys for the communicationssession. It was noted above that the values of the session keys arerotated and therefore change with each communications session. So, whenthe attacker tries to impersonate the device 200A, it is impossible forthe attacker to pass undetected to the device 200B because, when theattacker attempts to generate a new key for the next communicationsession with the attacked victim, i.e. the other device 200B, the secretkeys are not the same as those of the attacker (impersonator of deviceA), and the device 200B drops therefore the communication. In the firstiteration, the attacker will have an authenticated channel for acommunication session, but the attacker cannot complete the attackbecause the validation of the communications session will fail.

Supposition 3. The method and system are also secure against replayattacks. A replay attack is an attack that obtains information from onecommunication between the two devices 200A and 200B and tries to set theinformation in a next session or iteration of the communication betweenthe two devices 200A and 200B. For example, if the device 200A isexchanging a file with the device 200B, the attacker can send a piece ofthe previous file exchanged to try to corrupt the protocol for thecommunication. To solve this problem, the method and apparatus uses theproperties of key continuity and forward secrecy to generate a newsession key and make obsolete (i.e. not decipherable) those packets ofdata and encrypted information exchanged previously. This makes themethod secure against replay attacks because, if the attacker performsthis type of replay attack, the devices 200A and 200B will just ignorethe information sent and continue the ongoing transfer.

The proposed protocol is secure against backward and forwardtraceability attacks. Traceability can be classified as a passiveattack. In this scenario, the only task performed by the attacker is tolisten to the exchanged information between the devices 200A and 200Band try to understand patterns that lead to leakage of the information.

The approach adopted to overcome the traceability attack is to use theafore-mentioned Paranoid Mode, in which no local information is storedin the devices 200A or 200B. At any iteration of the communicationssession, a new identifier for all of the devices 200A and 200B isgenerated using the PRNG which makes it impossible to reproduce thecommunication schemes in the attacked session. This makes the methodsecure against traceability attacks.

The method and system are also resistant to single point of failure. Asdiscussed previously, in the case of PKI implementations, there is athird party (the certifying authority—CA), that checks the validity ofthe certificates. The CA establishes a link between public keys andidentities people or organisations. Therefore, customers in this PKIimplementation have to rely on a third party. The certificationauthority represents the single point-of-failure, as once the CA iscompromised, all of the peers in the network are compromised as well.For example, the Let's Encrypt CA has issued 15,270 “PayPal”certificates [Ref 28] to sites used for phishing. A failure in this typeof systems compromises several entities.

The system and method of this document, while facing an attack, can onlycompromise at most one of the devices 200A or 200B, not both of thedevices 200A and 200B.

MitM exploit to an attack on the SAS. Martin Petraschek et al. describethe MitM attack on the DH alone and state that, in the ZRTP, theauthentication can be made by comparing the SAS with voice recognition,which is mandatory for the first connection and optional otherwise (asit guarantees forward secrecy). However, it is possible that theattacker might try to imitate the voice of one of the parties, and thusdeceiving the other party. In this case the MitM attacker simplyforwards the RTP packets between the two devices 200A and 200B and canlisten into the conversation. Recent studies [Ref 24] show that thistype of attack is possible. For example, Lyrebird has a set ofalgorithms that clone anyone's voice by listening to just one minute ofaudio and this cloning could be used to generate the SAS.

The approach of this document addresses this problem with the additionallayer of security with the MPC. This additional layer of security hasthe goal of creating methods for the parties, i.e. the devices 200A and200B, to jointly compute a function over their inputs while keepingthose inputs private. This way, the comparison of the SAS can becomputed without revealing anything to other parties.

However, without identities, the MitM attack cannot be prevented in MPC[as known from Ref. 39]. In this method, there is a different approachthat can be utilised. The identities of the devices 200A and 200B do notneed to be valid because the probability of the attacker intercepting anMPC communication and, at the same time, being able to generate theinformation exchanged (SAS) equal to that of the other peer is very low.

This can be demonstrated by this example. Let α be the alphabetα={a,b,c, . . . ,z} with a size 26 (for the letters of the Latinalphabet) and β be the numbers β={0, 1, . . . , 9} with size 10. γ=α∪β

The probability of the generation of the same SAS by one of the devices200B of the other device 200A is calculated by the permutations withrepetitions with the formula: n^(r). Assuming the default length of theSAS is 4 (four) and the total number of characters (γ=36), we have n=γand r=4, so, we have γ⁴ possible cases.

Calculating the probability, we have only one possible case for theattacker to generate the same SAS of the other device. In other word,the probability of the same SAS being generated is almost zero.

${Probability} = {\frac{{Favourable}\mspace{14mu} {Outcome}}{{Possible}\mspace{14mu} {Outcome}} = {\frac{1}{\gamma^{4}} = {{{5.9}5e^{- 7}} \approx 0}}}$

The difference between the method and system outlined in this document,J-PAKE, and ZRTP will now be discussed. We shall start by analysing thetype of data that is used by each approach (audio vs. data), and alsothe security properties Forward Secrecy and Key Continuity. As the focusof the method and system is on the IoT network shown in FIG. 2, a checkwill be described to see if the approaches are ready for this type oftechnology and if it is possible to use as automatic provisioning.Finally, an analysis is carried out to see if there are multipleoperation modes in the other protocols, as the system and method of thisdocument has operation modes adapted to security or speed, depending ofthe needs of the user.

Automatic provisioning is a feature in the context of the IoT networkbecause automatic provisions leaves communication security not dependenton the user. In addition, many of the IoT devices in the IoT network donot have keyboards or screens. One source of error is that humans tendto make it easy to provision anything that pops up on a screen. Thehuman user may confirm the SAS, without actually questioning whether theSAS actually matches on both of the devices. Neither the J-PAKE nor theZRTP system offer safeguards against such human error.

The J-PAKE system requires two screens and a keyboard, at a minimum,because, for each of the devices, it is necessary to enter a key that isdisplayed on the screen to make the provisioning. A test was made usingthe Pale Moon Web-Browser, which continues to use J-PAKE as part of itsSync service. In the ZRTP method, human interaction is also neededbecause audio recognition is necessary to compare and validate the SAS,which requires a display and two buttons, at a minimum.

Both of the J-PAKE and ZRTP protocols are only partially IoT-ready, asboth of the protocols require human intervention and, as discussedabove, for the IoT network, human intervention is not appropriate.

This following section presents the results of the proposed system interms of network latency. The experiments were carried out in allimplemented modes described above, i.e. without key continuity; innormal mode; and, finally, in paranoid mode. These modes differ in termsof usage and complexity, as the MPC is not required in all iterationsgiven the key continuity. On the other hand, in some cases, it may beimportant to validate the SAS at every iteration of the communicationssession to ensure that the communication between any two of the devices200A and 200B is always secure.

The run time of the system and method versus the OpenSSL PKI system wasalso tested. In the PKI systems, the trust is constructed based onPublic Key Certificates, as discussed above.

The latency was measured over the network in the systems. Clock orchrono timers are used to measure the time that it takes to complete aparticular action. In this case, the communication between the devicebeing a server (receiver) and the device being a client (sender). If theclient sends data to the server and waits for a reply, then the overallduration can be measured, which should roughly estimate the Round-TripDelay time (RTD) between the client and server. The goal was to measurethe provision time of the system and method of this document compared tothe PKI-based system. The running time of the system and method with andwithout the MPC was also measured to assess the real order of magnitudeof extra delay due to the MPC and its contribution to the overalllatency.

This experimental section is divided into three parts. The first partconsists of the setup and configuration of the system for theexperiments, i.e., the devices that are used for the experiments, aswell as the operating systems for the devices. Then, the results of thedifferent modes implemented are presented, as well as a discussion onthe results. Finally, a comparison of the results of the system andmethod of this document with those of the PKI-based system aredisclosed.

In order to measure the results of the usage of this system in arealistic environment (low-resource devices), the experiments wereperformed using two common off-the-shelf Raspberry Pi 3 Model Bs runningCanonical's Ubuntu Core, a specialised operating system for the IoT.

The IoT network emerges from the interconnection of a plurality ofdevices. The environment as shown in FIG. 2 was created. The twoRaspberry Pi Bs are the devices 200A and 200B are connected over thenetwork 202 (i.e. the Internet). One of the Raspberry Pis 200A isconnected to the Internet using a wireless link 204, through a wirelessrouter (ASUS RT-AC3200) 205, and the other one of the Raspberry Pis 200Bis connected to the Internet 202 using a wired Ethernet link 203. It wasdecided to route the traffic through the Internet 202 to measureexecution time with network latency in a realistic scenario

In order to evaluate the method of this document, the provisioning timesin all three modes was measured. FIG. 3 depicts the scenario to beevaluated, representing the provisioning phrase.

To perform these measurements, the gettimeofday( ) system call was,using the setup shown in FIG. 2. The results are given in the tablebelow. For each mode, represented in Table III, and the correspondingiteration from 1 up to 10, these values are the average values after 10repetitions and the correspondent standard deviation of the average.

Without With Modes Iterations MPC (ms) MPC (ms) Method Without KC 1-10290 ± 2.27 9552 ± 49.36 9843 ± 50.49 Normal  1 288 ± 2.27 9457 ± 49.369745 ± 50.49 2-9  283 ± 1.78 —  283 ± 46.92 10 287 ± 1.78 9495 ± 45.289783 ± 46.92 Paranoid 1-10 291 ± 2.27 9506 ± 49.36 9798±

The “Without Key Continuity” mode does not require any extra storage inthe identifier file 200 in the devices 200A and 200B because it is notnecessary to store the previously exchanged keys. This “Without KeyContinuity” mode was determined to take an average time of approximately9843 ms±50.49 in all iterations. This Without Key Continuity” mode hassome advantages regarding security, as the mode never relies onpreviously exchanged keys and has key continuity, and also reducesstorage requirements. However, the running time is the highest of thethree modes.

The “normal” mode, unlike the previous “Without Key Continuity” mode,uses the concept of key continuity, as explained above. As such, thenormal mode requires extra storage for the key in the devices 200A and200B. However, as noted above, the MPC module 210 is used only every 10iterations (for example). In this case, the running time is 283 ms±46.92after the first iteration. In the first iteration, given the overhead ofthe MPC, the latency is 9745 ms±50.49. As we use MPC at every 10iterations, this results in a latency spike.

The “paranoid” mode is similar to the “normal” mode, as the paranoidmode also makes use of key continuity. However, this mode is “paranoid”to the point of always verifying the SAS through the MPC module 210 inall of the iterations, and thus not relying on key continuity.

In terms of latency, there is no difference between the “Without KeyContinuity” modes and the paranoid modes. Only the normal mode has asignificant lower latency when compared to the other two modes. Thisnormal mode runs the MPC module 210 every 10 iterations. All of theother iterations have a similar behaviour. On the upside, the averagerunning time for the remaining iterations is 283±46.92 ms.

In this normal mode, the main drawback is the additional storage isrequired in the devices 200A and 200B. The implicit trade-off is betweenstorage and latency.

In brief, the choice between the operation modes is dependent on thetype of devices 200A and 200B that are used, the communication linksbetween the devices 200A and 200B, and, ultimately, the functionalrequirements of the user of the IoT network.

As an authenticated channel is assumed, we added a time factor 6 to theruntime to represent the overhead associated with it. However, we assumethat this time factor 6 will represent more than 20% of the runtime.

FIG. 3 shows the PKI scenario to be evaluated. In this FIG. 3 is shown alocal client, represented by a local Raspberry Pi, and a server machinehosted in a remote Raspberry Pi (illustrated in the FIG. 2) provisionedwith DigiCert certificates. The remote certificates support the OCSPstapling that removes the complexity of the devices communicating withthe CA. The TLS server periodically questions the OCSP responder aboutthe validity of its own certificate and caches the response. The OCSPresponder returns an OCSP response, which is (directly or indirectly)signed by the CA that issued the certificates. The TLS client can treatthis stapled OCSP response in the same way, i.e., the certificate shouldonly be used if it has a valid timestamp and signature.

During the TLS handshake, the client announces support for OCSP staplingto the server. In turn, the server activates the Certificate Status flagif the server has supports for the Certificate Status Flag. This processis shown in step 1 in FIG. 3. During step 2, an SSL connection isestablished between the devices A and B. The goal is to measure thecertificate's OCSP (state) check latency on top of the latency added bySSL connection handshake.

To measure the latency of this scenario, s_client and s_server binariesfrom the OpenSSL library were used. The s_server service was run on theserver machine and the s_client run on the local machine. It waspossible obtain both the OCSP information and server/client handshakeresults. It was found that there was an average running time of 380ms±11.60 across the 10 iterations.

The system and method of this document running in the “normal” modeachieves therefore a latency reduction of 26% compared to the resultsusing PKI-based systems.

This document describes a novel solution for the provisioning of andlightweight communication between the IoT devices in the IoT networkthat makes use of a modified secure key exchange protocol, in which theaudio channel was replaced with data negotiation over MPC (KEAV). Threedistinct operational modes, with increasing levels of security scrutinyand overhead are defined. The IoT network can be used for multiple fixedsensors, but also could be used in a network for autonomous driving.

The disrupting problem of scalability and small-footprint devices, whichmust be addressed in the IoT market, should consider the “normal” modeas a solution for this environment. This mechanism, alone, is capable ofperforming authentication and attestation of security properties in thesmall IoT devices, without a large impact on CPU's or batteryconsumption. The local information stored can be redesigned, allowing,for example, for these modes to be used in the most frequently usedcommunication schemes, leaving the other modes for when there is a needfor sporadic communication. This would allow, for example, the detectionof new systems over the IoT network that come to replace old devices.

In another application of the system and method, the devices could beVoIP devices.

The work of Patricia R. Sousa, João S. Resende and Rolando Martins wassupported by a scholarship from the Fundação para a Ciência e Tecnologia(FCT), Portugal (scholarship numbers, SFRH/BD/135696/2018,PD/BD/128149/2016, SFRH/BPD/115408/2016).

This work of Luis Antunes was supported by Project “NanoSTIMA:Macro-to-Nano Human Sensing: Towards Integrated Multimodal HealthMonitoring and Analytics/NORTE-01-0145-FEDER-000016”, financed by theNorth Portugal Regional Operational Programme (NORTE 2020), under thePORTUGAL 2020 Partnership Agreement, and through the European RegionalDevelopment Fund (ERDF).

REFERENCES

-   1. Yang, Yuchen, et al. “A Survey on Security and Privacy Issues in    Internet-of-Things.” IEEE Internet of Things Journal (2017).-   2. H. Sundmaeker, P. Guillemin, P. Friess and S. Woelffle, “Vision    and Challenges for Realising the Internet of Things,” Cluster of    European Research Projects on the Internet of Things, 2010.-   3. Aman, Muhammad, Kee Chaing Chua, and Biplab Sikdar. “Mutual    Authentication in IoT Systems using Physical Unclonable Functions.”    IEEE Internet of Things Journal (2017).-   4. Umar, Amjad. Information Security and Auditing in the Digital    Age. nge solutions, inc, 2003.-   5. Hao, Feng, and Peter YA Ryan. “Password authenticated key    exchange by juggling.” International Workshop on Security Protocols.    Springer Berlin Heidelberg, 2008.-   6. Lancrenon, Jean, Marjan Å krobot, and Qiang Tang. “Two More    Efficient Variants of the J-PAKE Protocol.” International Conference    on Applied Cryptography and Network Security. Springer International    Publishing, 2016.-   7. Hao, Feng. “J-pake: Password authenticated key exchange by    juggling.” (2016).-   8. Hao, Feng, Ed. “Schnorr NIZK Proof: Non-interactive Zero    Knowledge Proof for Discrete Logarithm” (2013).-   9. Zimmermann, Phil, Alan Johnston, and Jon Callas. ZRTP: Media path    key agreement for unicast secure RTP. No. RFC 6189. 2011.-   10. Seo, Dong Hwi, and P. Sweeney. “Simple authenticated key    agreement algorithm.” Electronics Letters 35.13 (1999): 1073-1074.-   11. Goldreich, Oded. “Secure multi-party computation.” Manuscript.    Preliminary version (1998): 86-97.-   12. Toorani, Mohsen. “Security analysis of J-PAKE.” Computers and    Communication (ISCC), 2014 IEEE Symposium on. IEEE, 2014.-   13. Yao, Andrew C. “Protocols for secure computations.” Foundations    of Computer Science, 1982. SFCS′08. 23rd Annual Symposium on. IEEE,    1982.-   14. Hirt, Martin, Ueli Maurer, and Bartosz Przydatek. “Efficient    secure multi-party computation.” International Conference on the    Theory and Application of Cryptology and Information Security.    Springer Berlin Heidelberg, 2000.-   15. C++ Implementation of ZRTP protocol—GNU ZRTP    C++—https://github.com/wernerd/ZRTPCPP [Online; Accessed 30 Mar.    2017].-   16. Petraschek, Martin, et al. “Security and Usability Aspects of    Man-in-the-Middle Attacks on ZRTP.” J. UCS 14.5 (2008): 673-692.-   17. ABY—A Framework for Efficient Mixed-protocol Secure Two-party    Computation https://github.com/encryptogroup/ABY [Online; Accessed    15 Sep. 2017]-   18. Keller, Marcel, Emmanuela Orsini, and Peter Scholl. “MASCOT:    faster malicious arithmetic secure computation with oblivious    transfer.” Proceedings of the 2016 ACM SIGSAC Conference on Computer    and Communications Security. ACM, 2016.-   19. Huang, Yan, Jonathan Katz, and David Evans.    “Quid-pro-quo-tocols: Strengthening semi-honest protocols with dual    execution.” Security and Privacy (SP), 2012 IEEE Symposium on. IEEE,    2012.-   20. Sakarindr, Pitipatana, and Nirwan Ansari. “Security services in    group communications over wireless infrastructure, mobile ad hoc,    and wireless sensor networks.” IEEE Wireless Communications 14.5    (2007).-   21. Laud, Peeter, and Liina Kamm, eds. Applications of Secure    Multiparty Computation. Vol. 13. IOS Press, 2015.-   22. Device Pairing Using Short Authentication Strings (2016)    https://tools.ietf.org/id/draft-ietf-dnssd-pairing-01.html [Online;    Accessed 21 Apr. 2017]-   23. TLS Handshaking With Certificates and Keys (2017)    https://mcuoneclipse.files.wordpress.com/2017/04/tls-handshaking-with-certificates-and-keys.png    [Online; Accessed 25 Apr. 2017]-   24. Lyrebird claims it can recreate any voice using just one minute    of sample audio. (2017)    http://www.theverge.com/2017/4/24/15406882/ai-voice-synthesis-copy-human-speech-lyrebird    [Online; Accessed 25 Apr. 2017]-   25. Martini, S.: Session Key Retrieval in J-PAKE Implementations of    OpenSSL and OpenSSH. (2010)    http://seb.dbzteam.org/crypto/jpake-session-key-retrieval.pdf    [Online; Accessed 3 Apr. 2017]-   26. Thermos, Peter, and Ari Takanen. Securing VoIP Networks. Pearson    Education, 2007.-   27. Canetti, Ran. “Obtaining universally compoable security: Towards    the bare bones of trust.” International Conference on the Theory and    Application of Cryptology and Information Security. Springer Berlin    Heidelberg, 2007.-   28. Let's Encrypt issues certs to ‘PayPal’ phishing sites: how to    protect yourself (2017) http://bit.ly/2i7Z4bT [Online; Accessed 19    May 2017]-   29. Demmler, Daniel, Thomas Schneider, and Michael Zohner. “ABY-A    Framework for Efficient Mixed-Protocol Secure Two-Party    Computation.” NDSS. 2015.-   30. Yao, Andrew Chi-Chih. “How to generate and exchange secrets.”    Foundations of Computer Science, 1986, 27th Annual Symposium on.    IEEE, 1986.-   31. Yao, Andrew C. “Theory and application of trapdoor functions.”    Foundations of Computer Science, 1982. SFCS′08. 23rd Annual    Symposium on. IEEE, 1982.-   32. Lindell, Yehuda, and Benny Pinkas. “Secure multiparty    computation for privacy-preserving data mining.” Journal of Privacy    and Confidentiality 1.1 (2009): 5. APA-   33. McGrew, D., et al. “RFC 3711: The secure real-time transport    protocol (SRTP).” Cisco Systems, Inc and Ericsson Research, Tech.    Rep (2004).-   34. Zimmermann, P., J. Callas, and A. Johnston. “ZRTP: Media Path    Key Agreement for Unicast Secure RTP (RFC 6189).” (2011): 2070-1721.-   35. Sisalem, Dorgham, et al. SIP security. John Wiley & Sons, 2009.-   36. Hlavacs, Helmut, et al. “Enhancing ZRTP by using Computational    Puzzles.” J. UCS 14.5 (2008): 693-716.-   37. Petraschek, Martin, et al. “Security and Usability Aspects of    Man-in-the-Middle Attacks on ZRTP.” J. UCS 14.5 (2008): 673-692.-   38. Afifi, M. H., et al. “Dynamic Authentication Protocol Using    Self-Powered Timers for Passive Internet of Things.” IEEE Internet    of Things Journal (2017).-   39. Pass, Rafael. “Bounded-concurrent secure multi-party computation    with a dishonest majority.” Proceedings of the thirty-sixth annual    ACM symposium on Theory of computing. ACM, 2004.

1. A method for establishing a communication using encrypted messagesalong a communications channel between a first device and a seconddevice comprising: mutually discovering the first device and the seconddevice; validating the communications channel by establishing secretsession keys for the communications channel between the first device andthe second device; calculating a first authentication string (SAS) inthe first device and a second authentication string (SA) in the seconddevice; inserting the first calculated SAS in a first MPC module of thefirst device and the second calculated SAS in a second MPC module of thesecond device and confirming security of the communications channel byevaluating the first SAS in the second MPC module of the second deviceand the second SAS in the first MPC module of the first device;establishing, in the event of the confirmation of the security of thecommunications channel, a shared secret between the first device and thesecond device using the exchanged secret session key; and exchanging theencrypted messages along the communications channel.
 2. The method ofclaim 1, wherein the mutual discovering comprises providing identifiersbetween the first device and the second device.
 3. The method of claim2, wherein the providing of an identifier between the first device andthe second device comprising exchanging initiation and acknowledgementmessages between the first device and the second device, the initiationand acknowledgement messages include the identifiers.
 4. The method ofclaim 2, wherein the identifiers are provided by generating a randomnumber identification of at least one of the first device and the seconddevice.
 5. The method of claim 2, wherein the providing identifierscomprising receiving identifiers of the first device and the seconddevice from a server.
 6. The method of claim 1, wherein the validatingcomprises a first key exchange from the first device to the seconddevice and a second key exchange from the second device to the firstdevice.
 7. The method of claim 1, further comprising sending a confirmmessage from the first device to the second device and a confirm messagefrom the second device to the first device after successful comparisonof the exchanged messages.
 8. The method of claim 7, wherein a firstsecret key in the first key exchange is generated from a previous firstsecret key and a second secret key in the second key exchange isgenerated from a previous second secret key.
 9. The method of claim 1,wherein the validating of the communications channel is carried outbefore exchanging every message along the communications channel. 10.The method of claim 1, wherein the validating of the communicationschannel is carried out only after exchanging a number of messages alongthe communications channel.
 11. The method of claim 1, wherein themutual discovery of the first device and the second device is carriedout by automatic exchange of messages between the first device and thesecond device by one of a direct communication or using a server.
 12. Ause of the method of claim 1 in a network comprising a plurality of IoTdevices, including those on moving vehicles, or a plurality of VoIPdevices.
 13. A network comprising a plurality of devices, wherein theplurality of devices comprise: a transmitter for transmitting messagesalong a communications channel to one or more of the other ones of theplurality of devices; a receiver for receiving messages from thecommunications channel from one or more of the other ones of theplurality of devices; an identifier file for storing a session key; amulti-party computation module for receiving an authentication string(SAS) from one of the plurality of devices over a communications channeland confirming the security of the communications channel; and acommunications module for encrypting and decrypting messages to and fromthe communications channel using the session key.
 14. The network ofclaim 13, wherein the multi-party computation module is adapted to havea first authentication string and to receive a second authenticationstring from one of the other ones of the plurality of devices, andthereby confirming the security of the communications channel.
 15. Thenetwork of claim 13, wherein the devices further comprise a storage forstoring a plurality of session keys.
 16. The network of claim 13,wherein the devices further comprises a pseudo random number generatorfor generating an identifier identifying the devices.
 17. The network ofclaim 13 further comprising a server for providing the devices with anidentifier of another one of the devices.
 18. The network of claim 13,wherein the plurality of devices are devices in an IoT network, anautonomous vehicle network or VoIP devices.